A lot of software development is done using an iterative modify-review process. A developer modifies the source code—e.g., fixes a bug or adds a new feature. However, this modification cannot go into the project immediately—before it can be accepted, the modification needs to be reviewed—by the whole team or by one of more managers of the project.
In certain organizations, face-to-face reviews, where the developer presents his code to the reviewers, are possible. In many other organizations, however, the developers are spread across countries and time zones, or simply find it difficult to is coordinate a meeting, and the review is carried out from a distance, such as via email: the developer packages his proposed source-code modification in a patch file and sends this change information to the reviewers. Specifically, this procedure is common in peer-production models, such as open source development.
A “source code patch”, or “patch”, in the present disclosure is a set of modifications instructions to the source code that are conceptually associated, such as all modifications are aimed to a common goal such as to adding a feature or resolving an existing bug. A patch may be provided as a text file, such as generated using the diff software utility in Unix™ environment, as a revision in a source code control system, such as CVS™, Rational® ClearCase™, or the like.
In many occasions, the patch is accompanied by a human-readable description of the change, to make it easier for the reviewers to understand the patch. The reviewers can accept the proposed changes as-is, or request that certain issues be fixed, after which the developer should send the improved patch for another round of review—until the patch is finally accepted and “committed” into the main source code of the project.